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ABSTRACT 



A system and method are described for dptimizinggecess of) 
shared data. Briefly described, in architecture, the -system 
can be implemented as follows. The datj^o^_pptimization 
system includes < a liinkagejable that contains 'af least one 
uiiresolved''data module accessible by a cpmpjiterprogVam. 
The linkage table also includes a load determination logic 
that determines the location of the unresolved data module 
at load time of the computer program, and a load modifi- 
cation logic that modifies the load instruction in the com- 
puter program, at load time of the computer program, to 
directly load the unresolved data module at the location. The 
present invention can also be viewed as providmgr£;meJhpci> 
for effi ciently accessing^shared^data), In this regard, the 
method can be broadly summarized by the following steps: 
(l)CgeneTaang:aT li^ the computer program 

when a load instruction in the computer program loads an 
unresolved data that is not in a same load module as the 
computer program; (2) determining a location of the unre- 
solved data at load time of the computer program; and (3) 
modifying the load instruction at load time of the computer 
program to directly load the unresolved data at the location. 

20 Claims, 7 Drawing Sheets 
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SYSTEM AND METHOD FOR 
OPTIMIZATION OF SHARED DATA 

FIELD OF THE INVENTION 5 

The present invention is generally related to computers 
and computer programs and, more particularly, is related to 
a system and method for optimizing the access to shared 
data. 

DESCRIPTION OF RELATED ART 10 

As is known in the computer and software arts, an 
executable file is typically composed of several separately 

^compiled object modules and libraries. In the past, all of the 
code and data necessary to build an executable file was 35 
usually linked into one monolithic file. Nowadays, it is more 
likely that an executable file generated by a compiler and 
linker will be incomplete, requiring a~ pluTaht^^FsMfedj 

(libraries (or dynamically linked libraries in OS/2 and Win- 
dows parlance) and data files. The base executable program 2 o 
is linked together with any dependent shared libraries at load 
time to produce a complete program. 

There are many advantages to the foregoing configuration 
and technique. In particular, common functionality, such as 
the standard input/output (I/O) facilities of the C language, 25 
for example, can be shared among all of the processes 
running on the system, rather than requiring that each have 
its own private copy. When (a'plt^^^^fi^is^quired for 
a routine within a shared library, the vendor can ship a~new 
library, and all of the programs that depend on the library 30 
will automatically pick up the new code the next time they 
are executed, without the need for recompilation. 

For remote code access, such as in a function call, a 
jump/branch instruction is used to transfer control from one 
point in the code to another. If the function being called is 35 
in a different load module, a new piece of(code~called the; 

timport stub~can be used to serve as a local substitute for the 
real function (i.e. its purpose is to jump to the real function, 
and that import stub can be patched at load time with the 
actual address once the second load module has been 40 
loaded). Thus, there would be a cascaded jump (i.e. function 
A jumps to the import stub, which then immediately jumps 
to function B). Function calls typically accomplish this by 
using pc-relative (or ip-relative — same thing) addressing. 
The pc (program counter) or ip (instruction pointer) is the 45 
address of the current instruction. Then, the program code 
can jump from one point in the code to another simply by 
knowing the relative distance between the two places. 
For remote data access, a loafror store instruction is used y 

Ctojiccess an item of data in memory. If the item is in a 50 
different load module, an import stub can not be used (i.e., 
the import stub only works because it actually causes 
jumping to the import stub and transferring control). When 
loading or storing data, there is no transferring control to a 
new code block, the code control stays within the current 55 
code. Instead, the only choice is to have the compiler 
generate code that does an indirect access to the data, unless 
the compiler knows at compile time that the data will be in 
the same load module. Unfortunately, the remote data access 
technique comes with a performance penalty. Code access- 60 
ing data areas within the same toad module can be efficiently 
done because tbe complete physical layout of the data area 
is known at link time. Typically, the accessing code uses 
global pointer- relative addressing. However, access to 
remote data (i.e., dynamically-loaded library files) use more 65 
time-consuming instruction sequences, because the location 
of the remote data is not known until runtime. 
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Normally for function calls, the compiler makes the 
optimistic assumption that the function called is directly 
reachable. The import stub is provided at link time if that 
assumption proves false. However, for data accesses, the 
compiler makes the pessimistic assumption that the data to 
be accessed is in a different load module. This policy is 
necessary because cascaded loads are not possible in most 
architectures in the same way that cascaded jumps can be 
used to implement an import stub for a function call. 

Heretofore, software developers have lacked a system and 
method for accessing shared data in a more efficient way. 

SUMMARY OF THE INVENTION 

The present invention provides a system and method for 
optimizing access of shared data. Briefly described, in 
architecture, the system can be implemented as follows. The 
dataToad t ffiimiza tion system includes a linkage table that- 
contains'at least one unresolved data module accessible by 
a computer program. The data load optimization system also 
includes a load determination logic that determines the 
location of the unresolved data module at load time of the 
computer program, and a load modification logic that modi- 
fies the load instruction in the computer program, at load 
time of the computer program, to directly load the unre- 
solved data module at the location. 

The present invention can also be viewed as providing a 
method for efficiently accessing shared data. In this regard, 
the method can be broadly summarized by the following 
steps: (1) generating a linkage table for the computer pro- 
gram when a load instruction in the computer program loads 
an unresolved data that is not in a same load module as the 
computer program; (2) determining a location of the unre- 
solved data at load time of the computer program; and (3) 
modifying the load instruction at load time of the computer 
program to directly load the unresolved data at the location. 

Other features and advantages of the present invention 
will become apparent to one with skill in the art upon 
examination of the following drawings and detailed descrip- 
tion. It is intended that all such additional features and 
advantages be included herein within the scope of the 
present invention, 

BRIEF DESCRIPTION OF THE DRAWINGS 

The invention can be better understood with reference to 
the following drawings. The components in the drawings are 
not necessarily to scale, emphasis instead being placed upon 
clearly illustrating the principles of the present invention. 
Moreover, in the drawings, like reference numerals desig- 
nate corresponding parts throughout the several views. In 
the drawings: 

FIG. 1 is a block diagram of a user system showing a 
dynamic loader process with the data load optimizer of the 
present invention. 

FIG. 2 is a block diagram of the process for optimizing 
access to share data in the object program code. 

FIG. 3 is a block diagram of a known method for 
accessing data utilizing a direct GP relative access. 

FIG. 4 is a block diagram of a known method for 
accessing data utilizing an indirect access. 

FIG. 5A is a block diagram of the present invention 
showing the data load optimizer access of share data as 
shown in FIGS. 1 and 2. 

FIG. 5B is a block diagram of the present invention 
showing a direct load after utilizing the data load optimizer 
of the present invention as shown in FIGS. 1 and 2. 



04/16/2004, EAST Version: 1.4.1 



US 6,665,671 B2 

3 4 ^ 

FIG. 6 is a flow chart of the preferred method to perform of its own data items. Then, the loader is notified that the / 

the dynamic loader process with the data load optimizer of linkage table needs to be patched at load time when it knows 

the present invention as shown in FIGS. 1, 5A, and 5B. where the load module containing variable X is loaded, and 

FIG. 7 is a flow chart of the data loader optimizer process what is the variable's offset within that load module's data 

that optimizes the access of shared data with a direct access 5 segment. ^ 

to an external target as shown in FIG. 6. Generally, in terms of hardware architecture, as shown in 

nnTAn on nccroiDTinM nc the FIG " X > the computer 12 includes a processor 41, memory 

DblAILhD ULSCRIFJION Ub IHb 42> one or more devices 45 & 45, and/or one or more 

INVENTION output devices 46 that are communicatively coupled via a 

The present invention will now be described in detail with 10 local interface 43. The local interface 43 can be, for example 

reference to the drawings. Although the invention will be but not limited to, one or more buses or other wired or 

described in connection with these drawings, there is no wireless connectioas, as is known in the art. The local 

intent to limit it to the embodiment or embodiments dis- interface 43 may have additional elements, which are omit- 

closed therein. On the contrary, the intent is to include all ted for simplicity, such as controllers, buffers (caches), 

alternatives, modifications, and equivalents included within 15 drivers, repeaters, and receivers, to enable communications, 

the spirit and scope of the invention as defined by the Further, the local interface 43 may include address, control, 

appended claims. and/or data connections to enable appropriate communica- 

For remote code access, such; as in a function call, a v ^ons among the aforementioned components, 

jump/branch instruction is used to transfer control from one The processor 41 is a hardware device for executing 

point in the code to another. If the function being called is 20 software that can be stored in memory 42. The processor 41 

in a different load module, a new piece of code called the can be virtually any custom made or commercially available 

import stub can be used to serve as a local substitute for the processor, a central processing unit (CPU) or an auxiliary 

real function (i.e. its purpose is to jump to the real function, processor among several processors associated with the 

and that import stub can be patched at load time with the computer 12, and a semiconductor based microprocessor (in 

actual address once the second load module has been 25 the form of a microchip) or a macroprocessor. Examples of 

loaded). Thus, there would be a cascaded jump (i.e. function suitable commercially available microprocessors are as fol- 

A jumps to the import stub, which then immediately jumps lows: an 80x86 or Pentium series microprocessor from Intel 

to function B). Function calls typically accomplish this by Corporation, U.S.A., a PowerPC microprocessor from IBM, 

using pc-relative (or ip-relative) ^addressing. The pc U.S.A., a Sparc microprocessor from Sun Microsystems, 

(program counter) or ip (instruction pointer) is the address of 30 Inc, a PA-RISC series microprocessor from Hewlett- 

the current instruction. Then, the program code can jump Packard Company, U.S A., or a 68xxx series microprocessor 

from one point in the code to another simply by knowing the from Motorola Corporation, U.S .A. 

relative distance between the two places. The memory 42 can include any one or combination of 

For remote data access, a load or store instruction is used 35 volatile memory elements (e.g., random access memory 

to access an item of data in memory. If the item is in a (RAM, such as DRAM, SRAM, etc.)) and nonvolatile 

different load module, an import stub can not be used (i.e. memory elements (e.g., ROM, hard drive, tape, CDROM, 

the import stub only works because it actually causes etc.). Moreover, the memory 42 may incorporate electronic, 

jumping to the import stub and transferring control). When magnetic, optical, and/or other types of storage media. Note 

loading or storing data, there is no transferring control to a 4Q that the memory 42 can have a distributed architecture, 

new function, the code control stays within the current where various components are situated remote from one 

function. Instead, the only choice is to have the compiler another, but can be accessed by the processor 41. 

generate code that always does an indirect access to the data. The software in memory 42 may -include one or more > 

In an indirect access, the generated code in function A to separate programs, each of which comprises an ordered | 

access a variable X in some arbitrary load module must first 45 listing of executable instructions for implementing logical 

load a pointer to X from;a linkage table located in function :fuhctions. In the example of FIG. 1, the software in the 

A's load module (i.e. because that's the only load module memory 42 includes a suitable operating system (O/S) 48. A 

there is direct access to). Then, the code can use that pointer non-exhaustive list of examples of suitable commercially 

to load or store the actual location of variable X. In the prior available operating systems 48 is as follows: a Windows 

art, the loader initializes all the pointers in the linkage table 50 operating system from Microsoft Corporation, U.S.A., a 

for data accesses at the same time that it patches any import Netware operating system available from Novell, Inc., 

stubs for function calls. The present invention deals with U.S.A., an operating system available from IBM, Inc., 

optimizing the accessing of shared data. U.S. A., any LINUX operating system available from many 

For data access, gp-relative addressing is used. The gp vendors or a UNIX operating system, which is available for 

(global pointer) as a separate register in the processor that 55 purchase from many vendors, such as Hewlett-Packard 

holds the address of the data segment that belongs to the Company, U.S.A., Sun Microsystems, Inc. and AT&T 

Current load module, that is, the load module to which the Corporation, U.S.A. The operating system 48 essentially 

currently-executing code belongs. This allows each function controls the execution of other computer programs, such as 

to access its own data using a gp-relative address. but not limited to, the data load optimizer 140, dynamically 

To access remote data from a different load module, 60 loaded ubrar y files 5 ? and dynamic loader 120, and further 

however, the compiler knows neither the address of the data provides scheduling, input-output control, file and data 

segment for that load module nor the gp-relative offset of the management, memory management, and communication 

data item in that data segment— (i.e. those values are not control and related services, 

"^known until the program is loaded). Therefore, a linkage The data load optimizer 140 may be a source program, 1 

;table is created that holds a pointer to the data item the code 65 (executable program (object code), script, or any other entity 

is to access. The linkage table is placed in function A* s own comprising a set of instructions to be performed. When a 

^Jp^ad module, so it can access the pointer just as it would any source program, then the program is usually translated via a 
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compiler, assembler, interpreter, or the like, which may or (EPROM, EEPROM, or Flash memory) (electronic), an 
may not be included within the memory 42, so as to operate optical fiber (optical), and a portable compact disc read-only 
properly in connection with the O/S 48. Furthermore, the memory (CDROM) (optical). Note that the computer- 
data load optimizer 140 in the dynamic loader 120 can be readable medium could even be paper or another suitable 
written as (a) an object oriented programming language, s medium upon which the program is printed, as the program 
which has classes of data and methods, or (b) a procedure can be electronically captured, via for instance optical 
programming language, which has routines, subroutines, scanning of the paper or other medium, then compiled 
; and/or functions, for example but not limited to, C, C++, interpreted or otherwise processed m a suitable manner if 
Pascal, BASIC, FORTRAN, COBOL, Perl, Java, and Ada. ^cessary, and then stored in a computer memory. 
^ rrn , - i j - , • r , m In an alternative embodiment, where the data load opti- 
Ihe I/O devices may mclude input devices, for example w mizef ^ ^ ^ fc ^ m 

but not limited to, a keyboard 45 mouse 44, scanner, hardware , the data load opt i m i zer i 40 and dynamic loader 

microphone, etc. Furthermore, the I/O devices may also UQ caQ be ^ lemented with one or a comb inauon of 

include output devices, for example but not limited to a ^ followin technologies, which are each well known in 

pnnter, display 46, etc. Finally, the I/O > devices may further the art; a discrete ^ drcuit(s) havi x {c gates for 

mclude devices that communicate both inputs and outputs, « 1™^^ logic functions upon data signals, an appli- 

for instance but not limited to, a modulator/demodulator 47 cation mc inte ^ ated circuit (AS1C) having a pp ropr iate 

(modem; for accessmg another device, system, or network), combinatioria i i ogic gateS) a programmable gate array(s) 

a radio frequency (RF) or other transceiver, a telephonic (pGA)? a field programmable gate array (FPGA)j etc . 

interface, a bridge, a router, etc. ^ s(mrce prQgram 51 fa pfocessed by ^ progfam 

If the computer 12 is a PC, workstation, or the like, the compiler 52. The program compiler 52 generates a compiled 

software in the memory 42 may further include a basic input ob j ect program co de 53. Compiled object program code 53 

output system (BIOS) (omitted for simplicity). The BIOS is ^ ^nter processed by the linking program 54 to produce an 

a set of essential software routines that initialize and test executable object program 58. The linking program 54 

hardware at startup, start the O/S 48, and support the transfer generates the executable object program 58, the linking 

of data among the hardware devices. The BIOS is stored in progra m 52 must determine the offset to any access to 

ROM so that the BIOS can be executed when the computer remote code or data in first library 55, second library 56 and 

12 is activated. dynamic load library 57, or the like. When the linking 

When the computer 12 is in operation, the processor 41 is program 54 discovers that a data module accessed is not 

configured to execute software stored within the memory 42, 3Q within the same module as the compiled executable object 

to communicate data to and from the memory 42, and to program 58, the linking program 54 creates a linkage table 

generally control operations of the computer 12 pursuant to to access the code or data. The linkage table contains 

the software. The data load optimizer 140 in the dynamic pointers to the remote data. The first embodiment of the 

loader 120 and the O/S 48 are read, in whole or in part, by present invention involves a data load optimizer 140 that 

the processor 41, perhaps buffered within the processor 41, 35 upon program load can dynamically patch (i.e., rewrite code 

and then executed. in), the calling executable object program 58. This then 

When the data load optimizer 140 in the dynamic loader enables access to the shared data directly instead of using 
120 is implemented in software, as is shown in FIG. 1, it indirect access through linkage table, 
should be noted that the data load optimizer 140 and Illustrated in FIG. 2 is a diagram illustrating a process to 
dynamic loader 120 can be stored on virtually any computer 40 convert a program source code 51 into an executable pro- 
readable medium for use by or in connection with any gram object code 58 containing the modified shared data 
computer related system or method. In the context of this access feature of the present invention. The program source 
document, a computer readable medium is an electronic, code 51 is input into the program compiler 52 to generate a 
magnetic, optical, or other physical device or means that can compiled object program code 53 that is then processed by 
contain or store a computer program for use by or in 45 the program linker 54. The program compiler 52 lacking the 
connection with a computer related system or method. The location of dependent library files 55 and 56 and dynarni- 
data load optimizer 140 and dynamic loader 120 can be cally loaded library files 57 generates load code to be 
embodied in any computer-readable medium for use by or in processed by the program linker 54 in order to determine the 
connection with an instruction execution system, apparatus, displacement from the program object code 58 to the depen- 
or device, such as a computer-based system, processor- 50 dent library files 55, 56, and 57. 

containing system, or other system that can fetch the instruc- The program linker 54 takes the unresolved load code in 

tions from the instruction execution system, apparatus, or the compiled program object code 53 and determines their 

device and execute the instructions. displacement to dependent files 55 and dependent files 56. 

In the context of this document, a "computer-readable The program compiler 52 of the present invention creates a 

medium" can be any means that can store, communicate, 55 linkage table that allows the program object code 58 to 

propagate, or transport the program for use by or in con- determine the shared data module at runtime. The utilization 

nection with the instruction execution system, apparatus, or of these dynamically linked modules 57 are more expensive 

device. The computer readable medium can be, for example because of the relative placement of the caller module and 

but not limited to, an electronic, magnetic, optical, the caller module are not known until runtime of the 

electromagnetic, infrared, or semiconductor system, 60 program object code 58. 

apparatus, device, or propagation medium. More specific The dynamically linked library files 57 are enabled by a 

examples (a nonexhaustive list) of the computer-readable dynamic loader 120. The dynamic loader 120 is a system 

medium would include the following: an electrical connec- component, which is responsible for collecting all of the 

tion (electronic) having one or more wires, a portable necessary components of the program (executable file and 

computer diskette (magnetic), a random access memory 65 libraries) at run time and laying them out in memory. It is 

(RAM) (electronic), a read-only memory (ROM) also responsible for loading dynamically linked libraries 57 

(electronic), an erasable programmable read-only memory into memory as the running program requires them. 
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Illustrated in FIG. 3 is an example of a prior art method- The resolution of the symbolic references in the symbol 

ology of performing a remote data access. In the prior art, a table require the definitions for external references be found, 

remote data access is actually reference within module A 71 At step 126, the data load optimizer is performed. The data 

from function B 73 to data area 78.CTtie reference to data load optimizer is herein defined in further detail with regard 

area 78 is actually encoded as a load or store instruction with 5 to FIG. 7. At step 127, the dynamic loader 120 then binds all 

a global pointer plus displacement, where the displacement the code and data together for execution. The dynamic 

is the distance from the global pointer to the target data item loader 120 then exits at step 129. 

within data area 78. The call to data area 78 is actually FIG. 7 is a flow chart illustrating the architecture, 
encoded as a load with the program counter plus functionality, and operation of the dynamic load optimizer 
displacement, where the displacement is the distance from 1Q process 140 of the present invention, as shown in FIGS. 1, 
the program counter to the start of data area 78. This value 2, 5 and 6. First, the dynamic load optimizer 140 is initial- 
is filled in by the linker program 54. The user is to note that ized at step 141. At step 142, the data load optimizer 140 
this is a single step remote data access. examines the load instructions. rAt step-143, the data load 
Illustrated in FIG. 4 is the remote data access from optimizer 140 then determines whether the reference symbol 
module A 81 to module X 91 of the prior art. When function - , fe 131 ^ same load module. If it is determined at step 143 
B 83 within module A 81 references data area DD 95 within ^at the reference symbol is not in the same load module, the 
module X 91, the function B 83 first references the linkage <|ata ^ad optimizer 140 then skips to step 147. If it is 
table 86 that was created by the linker program 54. The de ™ e ? B ™ * e '° ad 

linkage table 86 then loads the remote data area DD 95 ™ dulc at V f data load \ . ^ 

■*u- 1 1 r»-( J* c , , -determines whether the reference symbol is located at a 

within module 91. The reference stil utihzes the load as 20 wfaose (o ^ ^ inter ^ ^ 

desenbed in FIG. 3 using a load (global pointer plus cnough If it is detcrmined ^ the global pointer relative 

displacement) from the hnkage table 86. The linkage table o£feet is not small enoughj the data ]oad optimizer 140 then 

86 computes a second global pointer plus displacement to sldps to step 147 However/if it is determined at step 144 

area DD 95 within module X 91. The displacement from that the global pointer relative ofifcet is small enough to be 

linkage table 86 to remote data area DD 95 within module ^ handled by the current system architecture, the data load 

X 91 is known only to the dynamic loader that is noted .optimizer 140 then replaces the linkage table load with the 

above. This load from the linkage table 86 to the remote data no-op instruction at step 145. The indirect load instruction is 

area DD 95 within module X 91 is computed at load time. then replaced with a direct load instruction at step 146. 

It should be noted that this is a two step data load for At step 147, the data load optimizer 140 then determines 

function B 83 to remote data area DD 95 with the interme- 30 whether there are more load instructions to be processed. If 

diate step utilizing the linkage table 86. it is determined at step 147 that there are more load 

Illustrated in FIGS. 5A and 5B is the remote shared data instructions to be processed, the data load optimizer 140 

access method of present invention. Shown in FIG. 5Ais a then returns to repeat steps 142 through 147. However, if it 

snapshot of module A 102 prior at compile time. Function B is determined at step 147 that the data load optimizer 140 is 

104A consists of a remote data load that calls the module a 35 done, the data load optimizer 140 then exits at step 149. 

linkage table 112 that is in data module HI to fix-up the a The data load optimizer 140 is program code, which 

remote data load. The linkage table 112 contains the load comprises an ordered listing of executable instructions for 

(fix-up and a branch to the remote module A data 113. The implementing logical functions, can be embodied in any 

dynamic loader 57 (FIGS. 1 and 2), calculates the displace- computer-readable medium for use by or in connection with 

ment between the module A linkage table 112 and the remote 40 an instruction execution system, apparatus, or device, such 

module A data 113 in data module 111. Once this displace- as a computer-based system, processor-containing system, 

ment is computed, the data load optimizer 140 (FIG. 1) of or other system that can fetch the instructions from the 

the present invention, modifies the load instruction within instruction execution system, apparatus, or device and 

function B 103 to include a load with an oflset of the execute the instructions. In,the context of this document, a 

program counter plus the displacement to the module A 45 "computer-readable medium" can be any means that can 

Hnkage table 112. contain, store, communicate, propagate, or transport the 

Furthermore, the load of the displacement to module A program for use by or in connection with the instruction 

linkage table modifies function B 104Ato become function execution system, apparatus, or device. 

B 104B so that any loads by function B 104B from remote The computer readable medium can be, for example but 

module A data 113 will be a direct single step load. This 50 not limited to, an electronic, magnetic, optical, 

method is more efficient, since the displacement to the electromagnetic, infrared, or semiconductor system, 

module A linkage table 112 can be^set at compile time, and apparatus, device, or propagation medium. More specific 

not at runtime. This avoids all the problems of rewriting examples (a nonexhaustive list) of the computer-readable 

code at load time. This also allows the remote module Adata medium would include the following: an electrical connec- 

113 to be changed at any time without constantly changing 55 tion (electronic) having one or more wires, a portable 

module A 102, thus providing more flexibility for the computer diskette (magnetic), a random access memory 

programmer. (RAM) (magnetic), a read-only memory (ROM) (magnetic), 

Illustrated in FIG. 6 is a flow chart showing the an erasable programmable read-only memory (EPROM or 
architecture, functionality, and operation of the dynamic Flash memory) (magnetic), an optical fiber (optical), and a 
loader 120 that manages the data load optimizer 140 of the 60 portable compact disc read-only memory (CDROM) 
present invention, as shown in FIGS. 1, 2 and 5. First, the (optical). Note that the computer-readable medium could 
dynamic loader 120 is initialized at ste p 121. At step 122, the even be paper or another suitable medium upon which the 
dynamic loader process loads the shared library cock. The program is printed, as the program can be electronically 
shared library data is then replicated at step 123. The captured, via for instance, optical scanning of the paper or 
dynamic loader process then loads the dynamic loader 65 other medium, then compiled, interpreted or otherwise pro- 
symbol table at step 124. At step 125, the dynamic loader cessed in a suitable manner if necessary, and then stored in 
120 resolves the symbolic references in the symbol table. a computer memory. 
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The foregoing description has been presented for pur- 
poses of illustration and description. It is not intended to be 
exhaustive or to limit the invention to the precise forms 
disclosed. Obvious modifications or variations are possible 
in light of the above teachings. The embodiment or embodi- 5 
ments discussed were chosen and described to provide the 
best illustration of the principles of the invention and its 
practical application to enable one of ordinary skill in the art 
to utilize the invention in various embodiments and with 
various modifications as are suited to the particular use 10 
contemplated. All such modifications and variations are 
within the scope of the invention as determined by the 
appended claims when interpreted in accordance with the 
breadth to which they are fairly and legally entitled. 

What is claimed is: 15 

1. A method to optimize dynamic data loads in a computer 
program, the method comprising the steps of: 

providing a compiler-generated linkage table for the com- 
puter program when a load instruction in the computer 
program loads an unresolved data module that is not in 20 
a same load module as the computer program; 

determining a location of the unresolved data module at 
load time of the computer program using said compiler- 
generated linkage table; and 

modifying the load instruction at the load time of the 
computer program to directly load the unresolved data 
module at the location, 

wherein said compiler-generated linkage table is set at 
compiler time by a program compiler, and 30 

wherein a linker program performs said determining and 
said modifying. 

2. The method of claim 1, wherein the modifying step 
further comprises the steps of: 

determining if the unresolved data module is an indirect 35 
data load; and 

calculating an offset to the location of the unresolved data 
module, when the load instruction is not the indirect 
data load. 

3. The method of claim 2, wherein the modifying step *o 
further comprises the step of: 

determining if the computer program has sufficient space 
to modify the load instruction, when the unresolved 
data module is not the indirect data load. 

4. The method of claim 3, wherein the modifying step 45 
further comprises the step of: 

replacing the load instruction with a direct load instruc- 
tion to the unresolved data module if the computer 
program has sufficient space for the direct load instruc- 
tion. 50 

5. The method of claim 4, wherein the replacing step 
further comprises the step of: 

using the offset to the location of the unresolved data 
module in the replacing of the direct load instruction, 

6. A data load optimization system, comprising: 
a compiler-generated linkage table that includes at least 

one unresolved data module accessible by a computer 
program; 

a load determination logic that determines a location of an 60 
unresolved data module at load time of the computer 
program using said compiler-generated linkage table; 
and 

a load modification logic that modifies the load instruction 
in the computer program to directly load the unresolved 65 
data module at the location at load time of the computer 
program 
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wherein said compiler-generated linkage table is set at 
compiler time by a program compiler, and 

wherein a linker program includes said load determination 
logic and said load modification logic. 

7. The system of claim 6, wherein the load determination 
logic further comprises: 

a unresolved data logic that determines if the unresolved 
data module is an indirect data load; and 

a calculation logic that calculates an offset to the location 
of the unresolved data module, when the load instruc- 
tion is not the indirect data load. 

8. The system of claim 6, wherein the load modification 
logic further comprises: 

a space logic that determines if the computer program has 
sufficient space to modify the load instruction, when the 
unresolved data module is not the indirect data load. 

9. The system of claim 8, wherein the load modification 
logic further comprises: 

a replacement logic that replaces the load instruction in 
the computer program with a direct load instruction to 
the unresolved data module if the computer program 
has sufficient space for the direct load instruction. 

10. The system of claim 9, wherein the replacement logic 
uses the offset to the location of the unresolved data module 
in the replacing of the direct load instruction. 

11. A system to optimize dynamic data loads in a com- 
puter program, comprising: 

compiler means for generating a linkage table for the 
computer program when a load instruction in the com- 
puter program loads an unresolved data module that is 
not in a same load module as the computer program; 

linking means for determining a location of the unre- 
solved data module at the load time of the computer 
program using said linkage table; and 

linking means for modifying the load instruction at the 
load time of the computer program to directly load the 
unresolved data module at the location. 

12. The system of claim 11, wherein the modifying means 
further comprises: 

means for determining if the unresolved data module is an 

indirect data load; and 
means for calculating an offset to the location of the 

unresolved data module, when the load instruction is 

not the indirect data load, 

13. The system of claim 12, wherein the modifying means 
further comprises: 

means for determining if the computer program has 
sufficient space to modify the load instruction, when the 
unresolved data module is not the indirect data load. 

14. The system of claim 13, wherein the modifying means 
further comprises: 

means for replacing the load instruction with a direct load 
instruction to the unresolved data module if the com- 
puter program has sufficient space for the direct load 
instruction. 

15. The system of claim 14, wherein the replacing means 
uses the offset to the location of the unresolved data module 
in the replacing of the direct load instruction. 

16. A computer readable medium for optimizing loading 
of shared data for a computer program, comprising: 

compiler logic that generates a linkage table for the 
computer program when a load instruction in the com- 
puter program loads an unresolved data module that is 
not in a same load module as the computer program; 
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linking logic that determines a location of the unresolved 

data module at load time of the computer program 

using said linkage table; and 
linking logic that modifies the load instruction at the load 

time of the computer program to directly load the 

unresolved data module at the location. 

17, The computer readable medium of claim 16, wherein 
the logic that modifies further comprises: 

logic that determines if the unresolved data module is an 

indirect data load; and 
logic that calculates an offset to the location of the 

unresolved data module, when the load instruction is 

not the indirect data load. 

18. The computer readable medium of claim 17, wherein 
the logic that modifies further comprises: 
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logic that determines if the computer program has suffi- 
cient space to modify the load instruction, when the 
unresolved data module is not the indirect data load. 

19. The computer readable medium of claim 18, wherein 
the logic that modifies further comprises: 

logic that replaces the load instruction with a direct load 
instruction to the unresolved data module if the com- 
puter program has sufficient space for the direct load 
1 instruction. 

20. The computer readable medium of claim 19, wherein 
the logic that replaces uses the offset to the location of the 
unresolved data in replacing of the direct load instruction. 

* * * * * 
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